Threshold Ed25519 Signatures

Talk Outline

1. Definitions and Concepts
2. Ed25519
3. Ed25519 Complications for Threshold Signatures
4. Current Standardisation Drafts
5. The TIDE System for Threshold Ed25519 Signatures

Elliptic Curve Cyptography Overview

For the purposes of cryptography, an elliptic curve is any one of the following forms:

• y2=x3+ax+b (a Weierstrass curve)
• by2=x3+ax2+x (a Montgomery curve)
• ax2+y2=1+dx2y2 (a Twisted Edwards curve)

Where x,y are unknowns in some field F and a, b, and d are constants in the same field.

The field F is usually a finite field Zp (or, equivalently, GF(p)) for some prime p.

Given any two points P1,P2∈E(F) there is a method of adding P1 and P2 to find a new point P1+P2∈E(F).

The set E(F) with this addition method forms a group with all that entails.

Of particular interest in this talk is the group associativity property: (P1+P2)+P3=P1+(P2+P3)∀P1,P2,P3∈E(F)

There is a natural action of the integers on this group wherein given k∈Z: kP:=P+P+⋯+P⏟k times Note: this action has a distributive property: (k1+k2)P=k1P+k2P.

The hardness of this problem is the basis of the security of elliptic curve cryptography.

Shamir Secret Sharing

A secret s∈Zp can be shared in a t-in-n sharing scheme wherein n actors have shares of the secret and any t or more may combine their shares by:

• Randomly generating an degree t−1 polynomial P such that P(0)=s
• Give each of the n actors a share σi=(xi,P(xi)).

Any subset of shares {σc∣c∈C⊂{1,…,n}} (where |C|≥t) can resconstruct the secret by s=∑c∈CP(xc)lc(C)whereli(C)=∏c∈C,c≠ixcxc−xi

c.f. “How to Share a Secret” by Adi Shamir in Commun. ACM November 1979

Threshold Signatures

Such a signature might be composed of otherwise valid signatures.

Individual contributions can be combined directly, or via Shamir secret sharing.

Ed25519

For reference:

• S. Josefsson and I. Liusvaara.
  Edwards-curve digital signature algorithm (eddsa).
  RFC 8032. January 2017.
  Available at: https://datatracker.ietf.org/doc/html/rfc8032.
• Daniel J Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang.
  High-speed high-security signatures.
  Journal of Cryptographic Engineering, 2(2):77–89, 2012.
  Available at: https://ed25519.cr.yp.to/ed25519-20110926.pdf.

Ed25519

In the specific case of Ed25519 we use the twisted Edwards curve E(Zp)={(x,y)∈Z2p∣x2+y2=1+121665121666x2y2} where p=2255−19.

Specifically, calculations are performed over the cyclic subgroup generated by the point G=(x,45) with positive x-coordinate. This subgroup has prime order ℓ=2252+27,742,317,777,372,353,535,851,937,790,883,648,493

Note: points in E(Fp) that are not in this cyclic subgroup must have order 1, 2, 4, or 8.

E(Fp) is bi-rationally equivalent to Curve25519 (a Mongtommery curve for key exchange).

CITATION NEEDED

Ed25519 Key Generation

To generate a public/private key pair for Ed25519 signing:

1. Generate 32 random bytes in a cryptographically secure manner.
   Call this s, and refer to it as the “secret seed”.
2. Calculate h=SHA512(s).
3. Split h into two halves.
   • H1=h0,…,h255
   • H2=h256,…,h511
   We refer to H2 as the “signing prefix”.
4. Key Clamping:
   • Clear the bits h0, h1, h2, and h255 in H1. (i.e., set them to zero).
   • Set the bit h254 (i.e., set it to one).
5. Let a=∑255i=0hi2i (i.e., interpret H1 as a number). We refer to this as the “secret scalar”.
6. We calculate the public key A=aG.

Note: aG=(amodℓ)G.

Ed25519 Key Clamping

The bit manipulation (sometimes called “clamping”) of the bits of H1 in step 4. guarantees that a is a multiple of 8.

This step is also peformed in the key generation for Curve25519 public keys where it provides an important protection against attacks in the key exchange using low order points outside of the cyclic group.

The reason for it in Ed25519 is not clear, and causes some difficulties in security proofs (see the CRYPTREC Investigation Reports on Cryptographic Techniques in FY 2020 — in particular Steven D. Galbraith's “CRYPTREC Review of EdDSA”).

We note in passing that clamping will have the effect of guaranteeing that all keys for Ed25519 are bi-rationally equivalent to valid keys for Curve25519.

Ed25519 Signing and Verification

Given a message, M, we sign the message by:

1. Calculate R=rG where r=NUM(H2‖M).
2. Calculate k=NUM(R‖A‖M).
3. Calculate S=(r+ka)modℓ.
4. The signature is the pair (R,S).

To verify a signature:

1. Verify that R and A correctly encode points, and that 0≤S<ℓ.
2. Calculate k=NUM(R‖A‖M).
3. Check that (8S)G=8R+(8k)A.

Ed25519 for Threshold Signatures

We note that if (a1,A1) and (a2,A2) are valid Ed25519 key pairs (i.e., secret scalar and public key), then because of the associative property of curve addition: (a1+a2)G=a1G+a2G=A1+A2 and so (a1+a2,A1+A2) is also a valid Ed25519 key pair.

Similarly, if in signing, if R1=r1G and R2=r2G then (r1+r2)G=R1+R2.

If we fix k=NUM(R1+R2‖A‖M) then if S1=(r1+ka1)modℓ and S2=(r2+ka2)modℓ then S1+S2=(r1+ka1)modℓ+(r2+ka2)modℓ=(r1+ka1+r2+ka2)modℓ=((r1+r2)+k(a1+a2))modℓ

Complications for Threshold Signatures

• There is no clear threshold signing prefix value.
  • Sum of individual signing prefixes is not the same as the signing prefix for the aggregate public key.
  • Deterministic nonce r might allow leaking of private key.
• Bit manipulations in key generation.
  • Distributive property of the group action mean that aggregate public keys will still be a multiple of 8.
  • Setting of 2nd-most significant bit makes it unclear if the aggregate key will still be a key that could be generated directly.
• Need to agree on value of k for signing.
  • Probably not an issue in practice; will require some communication.

Standardisation Drafts

There are currently two IETF drafts relating to threshold schemes for elliptic curves, both by P. M. Hallam-Baker

• “Threshold Modes in Elliptic Curves”
  • https://datatracker.ietf.org/doc/html/draft-hallambaker-threshold
  • A more broad description of threshold schemes for elliptic curves (including signing, key exchange, etc)
  • Focuses on Ed25519/X25519 and Ed448/X448.
• “Threshold Signatures in Elliptic Curves”
  • https://datatracker.ietf.org/doc/html/draft-hallambaker-threshold-sigs
  • Specifically covers threshold signature schemes for Ed25519 (and Ed448)
  • Strictly speaking, this draft expired in July 2021.

Hallam-Baker Drafts

• Gives a threshold threshold signing-method that works both directly and via Shamir secret sharing.
  • Two roles: “dealer” and “signer”. Dealer requests signatures (and controlls the flow), and signers perform signature.
• Points out several attacks.
  • Of particular note: the deterministic value of r when signing can be exploited by the dealer to potentially discover the signing keys of the signers. Recommends random generation instead.
• Notable absense of method to generate keys for Shamir secret sharing variant.
  • The section named “Distributed Key Generation” has content consisting of only “[TBS]”.

Hallam-Baker Signing Protocol

We assume that each signer, Ψi has a keypair (ai,Ai ).

1. Dealer selects and notifies signers, sends M to signers.
2. Each signer, Ψi:
   1. Randomly genrates 1<ri<ℓ and calculates Ri=riG
   2. Transmits Ri to the dealer.
3. The dealer (perhaps at some later point) may complete the signature by:
   1. Calculating R=∑iRi
   2. Calculating ci for each Ψi. ci={1for direct signaturesli(C) if Shamir secret sharing is used
   3. Transmiting R, A, and ci to each signer Ψi.
4. The signers may complete their contributions by:
   1. Computing k=NUM(R‖A‖M)
   2. Computing Si=(ri+kciai)modℓ
   3. Transmiting Ri and Si to the dealer.
5. The dealer completes the signature by:
   1. Computing S=∑iSi
   2. Verifying that the signature (R,S) is valid

TIDE System

• The TIDE system uses the same signing protocol as Hallam-Baker
• TIDE have solved the distributed key generation problem absent in the Hallam-Baker drafts, using the swarm random number generator described by Geetika.
• No actor—nether the user (the dealer), nor the ORKs (the signers and key generators)—ever sees or the aggregate secret scalar.
• The aggregate secret scalar is never stored.
• Signing is nonetheless possible becuse of the Shamir secret sharing implemented in the swarm random number generator.

TIDE Swarm Ed25519 Key Generation

1. The users selects n ORK's to generate the key and act as signers.
2. Each ORK, Oi generates
   • A secret scalar ai.
   • A t-in-n Shamir secret sharing polynomial Pi(x) to share secret ai
   in addition, Oi, also has a known unique (to the Swarm) x-coordinate, xi.
3. Each ORK, Oi calculates:
   • Public key Ai=aiG.
   • Shares (xj,Pi(xj)) of its secret scalar for all other ORKS, Oj in the swarm. These are encrypted.
   and transmits these to the user.
4. After receiving responses from all ORKs in the swarm, the user:
   1. Calculates A=∑iAi.
   2. Transmits to each ork, Oi the value A and all shares (xi,Pj(xi)) for that ORK.
5. Each ORK, Oi calculates it's share of the aggregate secret scalar σi=(xi,∑nj=1Pj(xi))

The aggregate secret scalar is a=∑ni=1ai.